Day 22｜讓 Bug Hunter 自己找問題，再交證據給我

前言

經過前幾天的培養，新同事終於可以當我的代理人，開始獨立處理事情了。之前得由我一步步下指令，今天可以讓它照流程自己跑，最後列出結果，再讓我幫忙審核就好。

這一步也是為了將來輪值做準備。輪值時我可能不在身旁，新同事得靠自己處理，總不能每一步都停下來等我，畢竟我可不想在半夜的時候被叫起來上廁所。

回歸正傳，前面幾天我們已經學會怎麼探索問題、判斷是不是 bug、打信心指數，以及去除重複的問題。今天把這些步驟串起來，交給一位代理人（Agent）執行。

我們只需要給它一句話，它就會跑完整個流程，交回候選問題和證據，讓我這個資深的前輩審核。不過，今天先讓它找問題、交證據，開單的權限還沒給它，後面再說。

開始之前

bug-hunter 開跑前會先檢查三件事，缺一項就先停下來補齊：

• charter（探索任務書）檔案存在且可讀：沒有 charter，代理人不知道要巡查哪個範圍、邊界在哪裡。若沒有，先叫 exploration-charter 產生一份 charter。
• output/known-false-positives.yaml 與 output/issues-index.yaml 存在：前者記錄已確認的誤報，後者記錄已有的問題，讓它知道哪些該過濾、哪些是重複發現。
• 先讀設定與交接規則：Bug Hunter 要讀取配套 sdet-skills 專案裡的 references/config-resolution.md 與 references/agent-handoff.md。前者告訴它這個專案使用哪些門檻與預算，後者說明交接時要保留哪些欄位（project、session、finding_id），免得下一位同事接手後不知道這筆問題從哪來。

這裡會用到前面幾天留下的東西：charter 是 Day 15 的產物，問題索引與誤報名單則是這幾天陸續累積的紀錄。現在把它們一起交給新同事，讓它接著做。

如果沒有 charter 內容，可以使用 /exploration-charter 產生 charter，或者閱讀第 15 天的文章。

/sdet-skills:exploration-charter 探索 https://with-bugs.practicesoftwaretesting.com 的登入到購物車流程，尋找數量與購物車狀態相關的 bug

它會產出一份新的 charters/toolshop-login-cart.yaml，欄位長相跟 Day 15 那份一樣：goal、scope、oracles、out_of_bounds、test_account、max_steps。唯一缺少的是一行 notes，那是 Day 15 那份特別留給 Day 19 更正用的，但不影響今天要跑的 bug-hunter。

動手試試

我們用下面這句 Prompt，讓新同事照先前建立的 charter去找問題：

用 charters/toolshop-login-cart.yaml 跑一輪 bug-hunter

順帶一提，這兩個 skill 的呼叫方式不一樣。我將 exploration-charter 設計成 user-invoked，要由使用者輸入斜線指令呼叫；bug-hunter 則是 model-invoked，允許模型依任務需要呼叫，所以前面才會直接用一句話請它開跑。

這樣安排，是為了讓未來的值班代理人 duty-oncall 能自己呼叫 bug-hunter。總不能半夜還要有人坐在旁邊，幫它輸入斜線指令吧。

但這也表示，什麼時候該用 bug-hunter，得讓模型判斷。skill 的 description 就要寫清楚適用情境，減少叫錯人的機會。

跑完之後

這次跑了約 30 分鐘，它交回一份 candidates.yaml，內容長這樣（節錄第一筆）：

- id: C-05
  fingerprint: "product-detail|quantity-field-not-reset-across-products|route-product-to-product"
  verdict: bug
  oracle_used: 內部一致性
  basis: >
    使用者未在新商品頁碰過數量欄，該欄卻沿用上一個商品輸入的值……
    同一 app 的另一條路徑（從列表頁進商品）同樣情境下顯示正確的 1，前後矛盾。
  confidence: high            # 0.25+0.25+0.20+0.10 = 0.80
  factors:
    - "3 次跨商品重現(p1→p2、p3→p4、p4→p5) +0.25"
    - "oracle=內部一致性(同一 app 兩條路徑結果矛盾) +0.25"
    - "證據齊(截圖/DOM 讀值/sessionStorage/步驟) +0.20"
    - "分類 product-bug、basis 指得到證據檔 +0.10"
  occurrences: 3
  evidence: output/evidence/.../packages/C-05-qty-leaks-across-products.md

這裡的 verdict: bug 是 Hunter 的初步判定，意思是它找到了判斷依據。這筆仍然是候選問題，還要交給明天上線的 Verifier 獨立驗證。

每一筆都要帶上 oracle 依據、信心指數的計分明細、指紋和證據路徑，缺一樣就還不能收工。不過，同一輪也記下了兩項執行流程上的問題，寫在執行紀錄（run log）的 process_notes 裡：

- 兩趟 hunter subagent 都出現『回報已完成但實際留有大缺口／未存證據』；下輪應在 hunter 收工前先驗『每候選是否指得到已存在的證據檔』再收。
- subagent 反覆把 typo 打信心指數 0.95；分數以 references/confidence.md 重算，未採信。

第一條是它說做完了，結果證據沒存，這不就跟我們偶爾也會犯的錯一樣嗎？第二條是它給自己的信心分數打太高，沒有照規則算，所以不能直接採用，得重新計算。

前面的範例只節錄了 candidates 裡的第一筆。整份 candidates.yaml 的結構如下，不同處理結果會分開放：

candidates: []      # 依信心指數排序，尚未開單
merged: []          # 指紋已存在，併入舊單的
related: []         # 疑似相同根本原因，交人判
suppressed: []      # 命中誤報名單，附命中哪條
needs_spec: []      # 無 oracle，附「該問誰」
stopped_because: 達標 | max_steps | 無進展

最後一行記錄這輪為什麼停下來，實際填入其中一個原因。上面的 [] 是空清單，跑完後再填入對應的紀錄；沒有符合的項目就維持空清單。

背後怎麼做

一句話就能開跑，是因為 skill 已經把下面這八步排好了，新同事照著做就行：

「標狀態」「初篩分類」「判定」看起來很像，其實各管各的：狀態記錄測試跑得怎樣，分類區分問題出在哪裡，oracle 判定則回答有沒有依據認定它是 bug。所以前面說狀態只能六選一，後面仍然會出現 bug、needs-spec 這些判定結果，它們填的是不同欄位。

第 4 到 7 步就是四道關卡，少一道就不算跑完一輪。第 1 步還有一件容易忘記的事：先讀同一份 charter 過去幾輪的紀錄，看看哪些已經驗過，把這輪的時間留給還沒探索的地方。

四道關卡要串著看：先用 oracle 判斷這個現象違反了什麼，再依規則計算信心分數，接著查指紋，看是不是舊問題，最後比對誤報名單，看是不是已經有人確認過的誤報。

沒有判斷依據，就先別急著說它是 bug。 還沒人說清楚怎樣才算對，標成 needs-spec；手上的證據還不夠，現在下不了結論，標成 inconclusive。

尤其是 needs-spec，要等有人釐清預期行為，再重新判斷。不能先把它算成 bug，也不能直接塞進誤報名單，當作沒這回事。

今天學到什麼

今天，我們把前幾章的探索、判斷、打分與去重步驟，串成 Bug Hunter 能自行執行的流程。只要給它一份探索任務，它就會交回候選問題，以及對應的操作步驟和證據。

不過，自動執行不代表結果可靠。這次它仍然漏存證據，也曾把信心分數打得過高。因此，驗收時必須檢查它實際留下了什麼，不能只相信它說「完成了」。

Hunter 交回的問題還需要獨立驗證。明天會加入 Bug Verifier，讓另一位沒有參與探索的代理人，照證據包中的步驟重新操作，確認同樣的現象是否再次出現。